Pin declared Anthropic MPS targets by family, like Bedrock - #376
Open
masonc08 wants to merge 5 commits into
Open
Pin declared Anthropic MPS targets by family, like Bedrock#376masonc08 wants to merge 5 commits into
masonc08 wants to merge 5 commits into
Conversation
`ucode claude --provider <mps>` sends whatever model string Claude Code's alias resolves to, and the gateway's direct-MPS path exact-matches that against the service's declared targets (then forwards it verbatim). For a Bedrock service ucode already pins ANTHROPIC_DEFAULT_*_MODEL to the service's target slugs, but for an API-key Anthropic service it pinned nothing and trusted Claude Code's canonical names to match — which they may not: a custom/dated target name, or an enterprise managed-settings pin like `system.ai.claude-haiku-4-5`, yields a 403 "not in the allowed models list". resolve_provider_models now derives the family->target map for a non-relayed Anthropic service too (map_claude_family_models already handles canonical ids), so the client sends exactly the ids the MPS declares. Bedrock is unchanged; relayed Claude Max/Enterprise stays exempt (model selection is off server-side). Co-authored-by: Isaac <no-reply@databricks.com>
lilly-luo
reviewed
Aug 27, 2026
Comment on lines
+322
to
+327
| # Pin the declared targets by family so the client sends exactly the ids the MPS | ||
| # allows. Bedrock always needed this (its slugs aren't Claude Code's canonical | ||
| # names); an API-key Anthropic service needs it too, else the client sends | ||
| # canonical names that may miss the declared targets and the gateway 403s with | ||
| # "not in the allowed models list". map_claude_family_models maps both Bedrock | ||
| # slugs and canonical Anthropic ids, and yields nothing for a non-Claude service. |
lilly-luo
approved these changes
Aug 27, 2026
lilly-luo
enabled auto-merge (squash)
August 27, 2026 21:43
The docstring and PR description already carry this rationale; the inline block was a third copy of it. Co-authored-by: Isaac <no-reply@databricks.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
ucode claude --provider <mps>sends whatever model string Claude Code's alias resolves to, and the gateway's direct-MPS path exact-matches that against the service's declared targets, then forwards it verbatim. For a Bedrock service ucode already pinsANTHROPIC_DEFAULT_*_MODELto the service's target slugs — but for an API-key Anthropic service it pinned nothing and trusted Claude Code's canonical names to match the declared targets.They often don't: a custom or dated target name, or an enterprise managed-settings pin like
ANTHROPIC_DEFAULT_HAIKU_MODEL=system.ai.claude-haiku-4-5, makes the client send a name that isn't a declared target → gateway403 … not in the allowed models list(and it wouldn't be a valid Anthropic model on egress either).Fix
Extend
resolve_provider_modelsto derive the{family: target}pin map for a non-relayed Anthropic service too — exactly as it already does for Bedrock.map_claude_family_modelsalready handles canonical Anthropic ids (and yields nothing for non-Claude services), so the client now sends exactly the ids the MPS declares. Bedrock is unchanged; relayed Claude Max/Enterprise stays exempt (the gateway disables model selection server-side for that tier).The managed (admin-manifest) path already pins Anthropic from authored slots, so this only closes the gap on the developer-configured path.
Caveat — managed-settings precedence
ucode writes
ANTHROPIC_DEFAULT_*_MODELinto its--settingsfile; enterprise/etc/claude-code/managed-settings.jsonmay outrank it. This fix reuses the exact mechanism Bedrock uses, so it takes effect wherever Bedrock MPS pinning already does. Decisive check: does a Bedrock MPS session pick up ucode's pinned slug on an Isaac-managed laptop today? If yes, this is sufficient everywhere; if no, both Bedrock and Anthropic need the separate managed-settings-scoping fix.Testing
tests/test_agents_init.py: flippedtest_anthropic_returns_no_models→test_anthropic_pins_family_targets; addedtest_anthropic_with_no_claude_targets_pins_nothing.ruff checkclean. Bedrock and relayed behavior unchanged (existing tests green).This pull request and its description were written by Isaac.